LoRaWAN’s Protocol Stacks: The Forgotten Targets at Risk

First, we compiled the code into something easily handled by a fuzzer. For our purposes, we used the generation method that will allow us to cover as many code paths as possible with legitimate and dumb fuzzing using the AFL++ framework (evolution of AFL). This supplies some instrumentation for mutating pseudorandom bits, bytes, and words.

We also attempted to collect every type of message that could be interpreted by the parser. We used the persistent mode to increase the fuzzing process speed from by x2 up to by x20. To deal with the amount of “uniq crash files” found in the repositories after fuzzing, we developed a classification method that can help users focus on the most interesting bugs first. 

The code would then be compiled to a different architecture than x86-64, and with a specific cross compiler with specific options. So, if we try to prove the vulnerability by exploiting it, more time will be wasted adapting the exploit to the right architecture. Firmware can also be closed source, so we need different methods to continue automatic bug finding. 

The following are two of the many methods that exist:

• Introducing stubs during debugging with GDB Pythons scripts, or with Frida on the few architectures supported by the tool
• Doing emulation with multiplatform engines such as Unicorn or Qiling

For this article, we have decided to demonstrate the use of the Qiling framework, which is a valuable tool used to quickly develop proof-of-concept emulators for multiple types of architectures. To demonstrate the tool in a straightforward way, and with symbols, we chose the LoRaMAC-node project, which is open-source but compiled in ARM. Qiling brings the UnicornAFL feature into the equation, so we not only use the framework to emulate, but also fuzz an emulated binary of a different platform. 

When it comes to emulating and fuzzing gateways, the architecture that is often encountered is MIPS MSB, which is not yet handled by Unicorn and Qiling. However, it is possible to use Ghidra with official processors as an alternative. For example, emulation can be performed with extended processors like Xtensa on Espressif chips. We discuss this in more detail in our full technical brief. 

Security recommendations for the LoRaWAN stack 

Stack developers and security teams handling LoRaWAN devices have to be vigilant and look out for vulnerabilities and memory corruption. The first step is to choose a protocol stack that has been approved by the community as well as tested by security researchers. Afterward, it is important to invest in fuzzing environments to check if the libraries used are resistant to the test cases scenarios that we outline in our technical brief.

The following image shows how fuzzing tests can be used in testing before releasing the LoRaWAN device: